I must admit I'm not familiar with the concept of snapshot versions, from what I understand it's like prerelease/rc versions? (I'll read a bit about it)

I think we should keep a consistant relation between the spec version and the package version, we can have multiple subversions at the same time.

For instance, let's say 0.6 is stable and 0.7 (main) is next, we can have 2 branches of the SDK, one with a 0.6.x package and one with 0.7.x package. Depending on the configuration, 0.6.x could be tagged as latest and 0.7.x could be tagged as next. Each branch of the project can have it's own independant schema registry URL configured in download-schemas.ts if needed.

One important note though, while porting the tests to the alternative approach` version, I noticed few problems. I think we should stabilize those before branching/handling multiple schemas versions

You can define the release strategy as you see best fit. If it helps some lets have a chat I could go over how we do it for the Java Sdk. Basic idea is to have release branches while "main" is indeed a "snapshot" which follows the specification "main" branch . But again that might not be the best strat for all Sdks.

the only requirement i think we need to have is to have ability to correspond a release with a spec version release. otherwise its really up to you guys to decide whats best approach :)

agree about having releases branch,

I will ask for help if I need for sure,

I just was wondering about how to publish "wip/snapshot" versions, probably I am just overcomplicating things, let's keep it simple..

I think it's managed with tags. If I'm not mistaken, by default, if no version is specified when running npm install/publish, the latest tag will be used. So if when you want to publish an unstable/beta version, you'd just use a different tag when publishing/installing.

For instance:

• package@1.0.0 latest
• package@1.0.1 latest
• package@1.0.2 latest
• package@1.0.3 beta

Running npm install package will install 1.0.2 and npm install package@beta will install 1.0.3. Publishing a new version, 1.0.4 will make it latest so the next user to install without specifing a tag (or have a semver restriction in the package.json) will get 1.0.4. In other words, you don't get the beta version unless you explicitly ask for it.